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PREFACE 
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Integration  Program  (PTIP),  Urban  Mass  Transportati on  Administration  (UMTA), 
U.S.  Department  of  Transportion,  by  the  Center  for  Applied  Mathematics, 
National  Engineering  Laboratory,  National  Bureau  of  Standards. 

Mr.  Edward  G.  Neigut  was  the  UMTA  program  manager  for  the  project. 


This  report  defines  the  functional  program  and  data  requirements  for 


automation  of  the  routing, 
paratransit  vehicles.  Its 
software  development.  The 
seri  es. 


scheduling  and  dispatching 
content  has  been  used  as  a 
software  will  be  described 


functions  for  a fleet  of 
specification  for 
in  other  reports  of  this 


i i i 


ABSTRACT 


This  document  specifies  functional  and  data  requirements  governing  automated 
procedures  for  routing  and  scheduling  dial-a-ride  vehicles.  It  provides 
overviews  of  existing  methods  and  proposed  methods,  and  summarizes 
improvements  and  impacts.  Requirements  for  functions,  performance, 
i nputs-outputs , data  characteristics,  and  failure  contingencies  are  discussed 
fully.  Three  operating  systems  are  specified.  Finally,  input  and  output  data 
are  described,  and  data  collection  procedures  are  presented. 

Keywords:  Automated  precedures;  data  requi rements ; dial-a-ride;  functional 

requirements;  operating  environment;  routing  and  scheduling 
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1.  GENERAL  INFORMATION 

Paratransit  services  are  defined  as: 

"...  those  forms  of  intraurban  passenger  transportation  which  are 
available  to  the  public,  and  distinct  from  conventional  transit 
(scheduled  bus  and  rail)  and  can  operate  over  the  highway  and  transit 
system. 1,1 

The  paratransit  systems  for  which  the  control  systems  described  in  this  report 
are  relevant  are  those  which  have  the  following  characteri sties: 

1)  Are  demand  responsive; 

2)  Use  coordinated  vehicle  dispatching; 

3)  Offer  shared-ride  service; 

4)  Are  available  to  the  public; 

5)  Operate  on  street  networks;  and 

6)  Follow  flexible  rather  than  fixed  routes  and  schedules. 

The  most  common  and  familiar  examples  of  systems  having  these  characteri sties 
are  dial-a-bus  and  shared-ride  taxi  (or  limousine)  services.  There  are  some 
300  known  systems1 2  of  this  type  currently  in  existence.  Almost  all  of  these 
systems  use  manual  routing,  scheduling,  and  dispatching  procedures. 

Automation,  if  it  exists  at  all,  is  typically  confined  to  accounting  type 
functi ons. 


1.1  SUMMARY 


Studies  have  indicated  that  in  a purely  manual  dial-a-ride  or  shared-ride  taxi 
system,  good  dispatchers  can  handle  from  seven  to  twelve  vehicles  effectively 

1 Ki rby , R.F. , et  al . , Paratransit:  Neglected  Options  for  Urban  Mobility, 
Washington,  DC:  The  Urban  Institute,  1974. 

Billheimer,  J.  W.,  et  al.,  Paratransit  Handbook,  Washington,  DC:  U.S. 
Department  of  Transportation,  UMTA-MA- 06-0054- 79-1,  1,  1978.  This  report, 
nominally  deals  with  how  to  implement  a paratransit  system.  It  contains  a 
wealth  of  paratransit  information  including  a taxonomy,  details  of  a number 
individual  systems,  and  an  excellent  bibliography. 
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with  the  use  of  such  aids  as  status  boards,  maps  and  pin  boards.  Beyond  that 
point,  effective  control  becomes  more  difficult,  assignments  may  not  be  as 
efficient  as  possible,  more  vehicles  may  be  used  than  are  really  required,  and 
qual ity-of-service  may  actually  decrease.  In  the  case  of  advanced  reservation 
or  subscription  services,  the  control  problems  are  not  quite  as  pronounced  as 
those  of  the  demand-responsi ve  services,  but  the  manual  development  of 
schedules  and  routes  may  not  be  the  best  possible,  depending  on  the  number  of 
vehicles,  geography,  times  for  pickup  and  delivery,  etc.,  and  it  may  be 
difficult  to  insert  late  reservations  in  a tour.  When  different  paratransit 
services,  or  similar  services  provided  by  different  operators,  require 
coordination,  or  centralization  in  order  to  promote  efficiency,  reduce  costs, 
and  provide  better  service,  then  manual  systems  could  become  very 
i neffi ci ent. 

Paratransit  services  are  implemented  and  are  generally  under  the  jurisdiction 
of  local  and  county  governments,  and  are  subject  to  higher  level  regulation, 
guidance,  funding  support,  etc.,  by  state  and  federal  governments.  The  types 
of  paratransit  services  and  their  degree  of  simplicity  or  complexity  are 
basically  determined  at  the  local  level.  Since  the  resources,  skills,  and 
available  monies  are  so  variable  at  the  local  level  throughout  the  country, 
UMTA's  paratransit  integration  program  must  be  flexible,  and  ensure  that  its 
R&D  products  can  meaningfully  satisfy  the  needs  of  the  widest  spectrum  of 
potential  product  users. 
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1.2  ENVIRONMENT 


The  paratransit  software,  when  developed,  should  consist  of  a number  of 
standardized  or  "off-the-shelf"  modules,  each  of  which  produces  some  output, 
to  another  module  or  to  an  operator,  to  be  used  for  totally  automating  the 
process,  or  expediting  the  manual  performance  of  dispatching,  routing,  and/or 
scheduling  of  paratransit  vehicles.  Each  of  the  modules  is  to  be 
cost-effective  in  the  context  of  the  total  paratransit  operation;  that  is,  use 
of  one  or  more  of  the  modules  is  to  result  in  incremental  benefits  greater 
than  the  incremental  costs  incurred,  for  a significant  class  of  paratransit 
operations.  Since  paratransit  systems  are  extremely  diverse  in  all  of  the 
important  attributes  (size,  goals,  target  population,  etc.),  it  is  not 
necessary,  nor  even  feasible,  for  each  module  to  be  appropriate  for  each 
operation.  The  goal  is  to  construct  a set  of  modules  of  which  some  subset, 
possibly  augmented  by  "manual  modules"  is  appropriate  for  a broad  variety  of 
paratransit  systems. 

The  concept  of  customizing  a control  system  by  combining  off-the-shelf  modules 
and  manual  functions  imposes  some  severe  and  unusual  requi rements.  The  soft- 
ware modules  must  interface  with  each  other,  with  manual  operations,  and  with 
non-control  software;  each  module  must  be  transparent  to  the  user;  each  must 
perform  a "natural"  function;  a hierarchy  of  fail-back  modes  must  be  provided 
and  portability  must  be  attained  over  hardware,  system  size,  and  the  geography 
and  demography  of  the  service  area. 
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1.3  LEVEL  OF  DOCUMENTATION 


To  facilitate  portability  of  programs,  all  will  be  written  in  ANSI  FORTRAN 
(ANSI  X3.9-1978)1.  Similarly,  all  flowcharts  will  conform  to  Federal 
Information  Processing  Standards  (FIPS)  242.  The  documentation  to  support  the 
programs  will  conform  to  FIPS  383  and  be  detailed  to  the  extent  that  it 
constitutes  a program  specification  should  a user  desire  to  rewrite  the 
program  in  any  appropriate  language. 


L American  National  Standard  Programming  Language  FORTRAN,  New  York:  American 
National  Standards  Institute,  ANSI  X3. 9-1978,  1978. 

2 Flowchart  Symbols  and  Their  Usage  in  Information  Processing,  Washington,  DC: 
National  Bureau  of  Standards,  FIPS  PUB  24,  1975. 

3 Guidelines  for  Documentation  of  Computer  Programs  and  Automated  Data 
Systems , Washington,  DC:  National  Bureau  of  Standards,  FIPS  PUB  38,  1976. 
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2.  OVERVIEW 


2.1  BACKGROUND 

The  paratransit  routing  and  scheduling  software  is  to  consist  of  modules 
compatible  with  each  other  and  with  manual  operations  as  well  as  other 
automated  procedures  (in  an  input-output  sense).  The  primary  thrust  is  to 
improve  the  control  function  of  paratransit  operations  for  a large  fraction  of 
the  existing  and  anticipated  systems.  Such  improvement  may  be  measured  by  the 
change  in  cost  or  response  time  of  the  control  system  itself  or  in  changes  in 
fleet  utilization,  service  quality,  profitability,  or  other  appropriate 
measures  of  operational  efficiency.  The  consideration  of  candidate  functions 
for  automation  is  not  limited  to  those  directly  involved  in  routing, 
scheduling,  and  dispatching.  In  fact,  several  non-control  functions  are  very 
attractive  for  automation  in  a cost-effective  sense.  Some  specific  examples 
are: 

(1)  Patron  eligibility  inventory  systems; 

(2)  Report  generation  for  monitoring  operations;  and 

(3)  Agency  billing  systems. 

The  software  is  to  be  a mix  of  on-line  and  off-line  operations.  Off-line 
functions  include  data  base  modifications,  statistical  calculations,  billing 
systems,  report  generating  systems,  global  optimization  systems,  and  patron 
acquisition  (patron-to-el igibi 1 ity  file)  systems.  On-line  functions  generally 
include  only  those  functions  directly  involved  with  vehicle  control,  a patron 
acquisition  (call  taker  or  eligibility  file  to  dispatcher)  system,  report 
generation  of  only  those  reports  needed  for  real-time  monitoring,  fall  Pack 
procedures,  or  rebooting.  Output  files  will  be  created  for  subsequent 
off-line  processing. 
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The  on-line  modules  are  further  partitioned  into  two  classes.  The  first  is  a 
real-time  command  and  control  system  concerned  with  fleet  control  and  the 
processing  of  patron  information  for  patrons  already  assigned  or  currently 
assignable.  This  subsystem  is  under  control  of  the  dispatcher.  The  second 
on-line  subsystem  is  real-time  in  a computer  sense,  but  not  in  the  command  and 
control  sense;  its  primary  function  is  patron  acquisition  from  a mix  of  input 
from  a call-taker  and  associated  data  bases. 

It  is  required  that  both  on-line  systems  operate  concurrently . This  may  be 
accomplished  via  mul ti-programming  or  multi-processing  within  a single  config- 
uration or  by  dedicated,  linked  configurations. 

Interfacing  among  the  on-line  subsystems,  the  off-line  subsystem,  external 
systems,  and  manual  operations  will  be  in  terms  of  input-output.  Files  and/or 
subfiles  must  be  amenable  to  transfer  among  subsystems;  it  is  not  necessary 
that  the  subsystems  be  interactive  in  a real  time  sense. 

2.2  PERFORMANCE  OBJECTIVES 

The  goal  is  for  the  system  to  include  an  automated  module  for  each  function 
for  which  such  a module  can  be  cost-effective  in  an  important  subset  of  para- 
transit  operations.  These  modules  must  interface  with  each  other  and  with  ex- 
ternal subsystems  in  such  a way  that  the  entire  system  is  "friendly."  Porta- 
bility must  be  attained  over  as  many  paratransit  systems  as  feasible.  The 
modules  envisioned  fall  into  three  classes  in  terms  of  somewhat  more  specific 
objectives.  These  correspond  to  the  off-1 i ne,  on-1 i ne,  and  real-time  environ- 
ments in  which  the  modules  will  operate. 
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The  off-1 i ne  modules  may  operate  in  batch  mode.  The  appropriate  measure  of 


performance  is  throughput  or  some  measure  related  to  or  derived  from 
throughput.  The  functions  performed  by  these  modules  include  file 
construction  and  maintenance  for  operational  files,  calibration  procedures  for 
data  retained  in  operational  files,  and  advanced  scheduling  and  routing  with 
associated  reports.  The  only  interfaces  with  the  other  portions  of  the 
operational  system  are  via  the  operational  files.  There  is  no  necessity  for 
an  operational  system  interface;  thus  the  off-line  modules  may  be  exercised  on 
a non-dedicated  configuration. 

The  on-1 i ne  modul es  will  be  concerned  primarily  with  patron  acquisition  wheth- 
er for  immediate  assignment,  deferred  assignment,  or  recurring  assignment;  and 
with  procedures  for  assuring  graceful  degradation  in  case  of  system  failures. 
Orderly  transition  between  automated  and  manual  modules  presents  an  especially 
difficult  problem.  For  these  modules  and  for  the  real-time  modules,  response 
time  is  the  appropriate  measure  of  performance. 

The  real-time  modules  will  be  exercised  concurrently  with  the  on-line  modules. 
They  interact  with  the  on-line  modules  via  the  sharing  of  some  data.  Their 
primary  functions  are  to  monitor  and  modify  vehicle  itineraries  and  assign 
patrons  to  vehicles.  The  modified  itineraries,  at  the  conclusion  of  the 
monitoring  procedure,  constitute  a history  file. 

For  the  most  part,  any  global  optimization  will  be  performed  within  the  off- 
line subsystem.  Real-time  optimization  will  not  be  attempted  except  perhaps 
some  limited  local  optimization. 
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2.3  EXISTING  METHODS  AND  PROCEDURES 


Existing  paratransit  systems  are  incredibly  diverse  in  all  important 
parameters  --  objectives,  target  populations,  service  areas,  size,  and 
equipment.  This  characteri sti c makes  the  modular  approach  mandatory;  the 
modules  must  accommodate  considerable  variation  in  the  important  parameters  of 
a prototype  system.  The  target  paratransit  systems  for  automated  aids  are 
expected  to  have  6 to  15  vehicles.  The  target  population  may  be  general, 
restricted,  or  mixed  by  time-of-day  or  desired  service  level.  Patronage  may 
be  subscri pti ve,  advanced  request  for  service  or  immediate  service.  This 
class  of  system  includes  almost  all  of  those  extant  except: 

(1)  Those  which  are  too  small  to  justify  even  modest  equipment  costs; 

(2)  Those  which  are  large  enough  to  justify  software  specifically 
tailored  for  local  requi rements ; and 

(3)  Those  which  are  integrated  closely  with  mass  transit  operations. 

The  reasons  for  excepting  the  first  two  classes  are  self-evident;  the  third 
class  is  excepted  because  of  the  excessive  resources  required  (time,  storage, 
data  base  construction,  and  managerial,  etc.)  to  store  explicit  networks 
required  for  mass  transit  stops,  schedules,  and  transfer  points. 

2.3.1  Organizational  and  Personnel  Responsibility 

A manual  control  system  for  the  candidate  paratransit  operation  would 
typically  include  several  call  takers  and  several  dispatchers;  the  exact 
staffing  being  heavily  dependent  on  service  mode,  target  population,  and 
funding  mechanisms.  In  most  cases,  operations  personnel  are  charged  with  many 
non-operational  tasks;  including  generation  of  management  reports,  billing 
activities,  and  eligibility  determination. 
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2.3.2  Equipment  Available  and  Required 


Almost  all  control  systems  include  voice  radio  for  each  vehicle  and  a base 
station.  A few  allow  digital  transmission  as  well.  Within  the  control 
center,  except  for  telephones,  this  includes: 

(1)  Manual  file  systems; 

(2)  Directories; 

(3)  Maps; 

(4)  A magnetic  chart  on  which  current  and/or  projected  vehicles  and/or 
patrons  are  displayed;  and 

(5)  A "tickler"  board,  essentially  an  incidence  matrix  of  vehicles  and 
time  intervals  in  which  the  entries  represent  assigned  patrons. 

2.3.3  Volume  and  Frequency  of  Inputs  and  Outputs 

Input  and  output  for  the  control  system  will  vary  considerably  with  the  opera- 
tional mode.  Normally,  there  will  be  an  input-output  for  each  patron  at 
acquisition,  at  assignment  to  a vehicle,  at  pick-up,  and  at  drop-off.  Thus, 
the  total  input-output  is  bounded  by  four  times  the  number  of  patrons  plus  a 
start  and  stop  for  each  vehicle.  Numerically,  this  means  about  20  inputs- 
outputs  per  vehicle  hour. 

2.3.4  Deficiencies  and  Limitations 

There  is  one  major  limitation  and  one  major  deficiency  in  the  manual  control 
center.  Both  of  these  are  intractable  without  a different  approach  to  the 
control  system. 
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The  major  deficiency  of  even  a small  manual  system  is  that  any  sort  of  optimi- 
zation is  simply  too  difficult  to  perform.  This  statement  is  true  for  both 
minimization  with  respect  to  patron  disutility,  system  disutility,  or  vehicles 
required  for  a prescribed  level  of  service;  and  maximization  with  respect  to 
vehicle  utilization,  revenues,  or  profitability.  Any  manual  system,  in  prac- 
tice, is  limited  to  providing  feasible  solutions  rather  than  optimal  or  even 
good  solutions.  Operational  consequences  include  the  possibility  of  high 
costs  and/or  poor  service  quality.  At  the  management  level,  there  is  no  way 
to  assess  whether  the  control  function  is  performed  well  or  poorly  relative  to 
the  resources  available. 

The  major  limitation  of  manual  systems  is  the  fact  that  the  complexity  of  the 
dispatching  problem  is  exponential  with  respect  to  the  number  of  patrons. 

This  is  a problem  that  has  not  been  (and  probably  cannot  be)  resolved  satis- 
factorily. Procedures  which  work  well  with  up  to  n vehicles  may  become  com- 
pletely impractical  for  2n  vehicles.  Attempts  to  avoid  this  blow-up  result  in 
other  difficulties;  the  most  common  of  which  is  the  transfer  problem  creat- 
ed by  fleet  partitions. 

2.3.5  Pertinent  Cost  Consi derations 

As  with  other  important  paratransit  characteri sties , costing  is  so  diverse  as 
to  defy  quantification.  Cost  per  worker  runs  the  gamut  from  free  (volunteer) 
to  well-paid  (organized  transit  workers).  The  entire  operation  can  be  charac- 
terized as  a labor-intensive  activity. 
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2.4  PROPOSED  METHODS  AND  PROCEDURES 


2.4.1  Organizational  and  Personnel  Responsibilities 

For  the  "typical"  paratransit  system,  control  system  organization  and 
personnel  are  not  expected  to  change  a great  deal.  Most  of  the  effects  of  the 
automated  system  will,  in  fact,  be  more  noticeable  (see  Section  2.5)  in 
non-control  aspects  of  the  system.  Since  the  fallback  control  mode  is 
expected  to  be  manual,  substantial  reduction  in  size  of  the  control  staff  per 
se  is  precluded  unless  management  is  willing  to  accept  a di fferent  type  of 
service  or  can  augment  the  control  staff  when  hardware  is  down.  The 
non-control  staff  may  be  reducible;  most  reporting  requirements,  for  example, 
may  be  met  by  fairly  simple  software  with  the  control  system  audit  trail  as 
i nput. 

Personnel  responsibilities  for  control  staff  will  be  changed  only  slightly. 
Proficiency  in  present  methods  must  be  maintained  to  provide  fallback.  The 
transparency  and  modularity  requirements  tend  to  make  the  functions  and  se- 
quences of  functions  very  much  alike  whether  the  system  is  manual  or  auto- 
mated. 


2.4.2  Equipment  Available  and  Required 

Except  for  the  computer  and  associated  peripheral  devices,  no  change  in  exist- 
ing equipment  is  envisioned.  Digital  transmission  to/from  vehicles  could  be 
useful  in  some  situations  and  its  possible  existence  must  be  accommodated. 
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Several  general  sorts  of  configuration  are  appropriate  for  different  types  of 
paratransit  operation.  For  real-time  control  modules  a dedicated  configura- 
tion is  required;  for  non-control,  on-line  modules,  either  a dedicated  system 
or  a time-shared  system  is  acceptable;  for  a subscription  or  advance  notice 
operation,  the  routing-scheduling  modules  may  be  run  even  in  a batch  mode. 

Any  combination  of  the  preceding  configurations,  augmented  by  appropriate 
input-output  interfaces  could  be  used. 

2.4.3  Volume  and  Frequency  of  Inputs  and  Outputs 

For  the  control  system  as  such,  input-output  is  expected  to  be  equivalent  to 
that  for  a manual  system.  Volume  will  be  slightly  reduced  since  much  input- 
output  will  be  coded  and  formatted.  There  may  be  an  increase  in  the  frequency 
of  input-output  due  to  the  better  monitoring  capability.  Provision  for 
interfacing  with  non-control  functions  or  actually  performing  such  functions 
(e.g.,  explicit  generation  of  transaction  log,  reporting,  generation  of 
subscription  trips,  etc.)  probably  will  cause  some  additional  input-output 
burden. 

2.4.4  Deficiencies  and  Limitations 

The  only  apparent  deficiencies  with  the  system  as  conceptualized  are  all  re- 
lated to  down-time.  First,  although  the  automated  system  will  speed  up  the 
processing  of  control  functions  and  result  in  more  efficient  utilization  of 
resources  of  the  paratransit  system,  the  requirement  for  a fail-back  system 
prevents  any  substantial  staff  reductions  (at  least  for  the  control  staff). 
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The  other  service  problems  arise  in  the  transition  to/from  automated  control 
from/to  manual  control,  and  in  the  prescription  of  acceptable  degraded  modes 
of  operation.  These  are  clearly  problems  of  procedures  external  to  the  soft- 
ware; however,  the  procedures  must  be  defined  and  formalized,  and  the  software 
must  support  them. 

2.4.5  Pertinent  Cost  Considerations 

The  most  important  cost  consideration  to  the  operator  is  the  procurement  cost 
of  the  hardware.  There  will  be  some  cost  incurred  for  training,  but  this  is 
expected  to  be  in  training  current  operating  staff  in  different  skill  areas. 
Software  development  costs  are  not  borne  by  the  operators;  software  mainten- 
ance costs  should  be  small. 

The  target  cost  for  a dedicated  configuration  is  expected  to  be  in  the  $ 25K  to 
$50K  range.  For  the  off-line  modules  (advance  or  subscription  only),  an 
upper  bound  for  costs  can  be  determined  by  comparison  with  service  bureau 
charges. 

2.5  SUMMARY  OF  IMPROVEMENTS 


Although  the  proposed  software  is  targeted  specifically  for  control  functions, 
many  of  the  improvements  realizable  will  be  more  noticeable  in  non-control 
areas.  These,  for  the  most  part,  will  become  attainable  because  the  structure 
and  content  of  the  data  interfaces  required  for  the  control  system  are  perti- 
nent for  other  functions  as  well.  The  specific  improvements  expecte  I or.? 
therefore  described  in  terms  of  those  improvements  due  to  the  propose! 
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system  and  those  peripheral  to  the  actual  control  and  scheduling  systems 
which  will  be  realizable  at  small  marginal  cost. 

2.5.1  New  Capabilities 

Since  the  control  and  scheduling  system  is  a set  of  modules  each  of  which  is 
designed  to  replace  a "manual  module,"  there  will  be  no  new  capability  in  the 
control  and  scheduling  system  per  se.  Several  important  new  capabilities  for 
supporting  functions  will  be  attainable  by  utilization  of  the  data  base 
(required  for  control  functions)  and  the  control  audit  trail  (required  for 
fall-back).  All  operational  data  will  be  available  in  formatted  form. 
Detailed  information  will  be  useful  for  reports,  trip  tickets,  billing, 
mailing  labels,  etc.,  at  a very  moderate  cost;  summaries  and  reports  for  many 
management  functions  not  related  to  direct  vehicle  control  will  also  be  easy 
to  generate. 

2.5.2  Upgrading  of  Existing  Capabilities 

Direct  upgrading  is  expected  in  two  major  areas.  First  and  most  obvious  is 
that  optimization  methodologies  are  incorporated  in  some  of  the  modules;  in 
some  cases  these  are  global  optima;  in  others,  local.  Either  sort  of  op- 
timization is  too  complex  and  time-consuming  to  attempt  in  a manual  system. 
Any  of  several  important  characteri sties  may  be  optimized:  utilization  of 

equipment,  quality  of  service,  etc. 
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A second  major  area  in  which  substantial  improvement  is  expected  is  in  the  im- 
proved information  available  to  manual  elements  of  the  control  system.  Infor- 
mation will  be  more  complete  and  of  better  quality  as  well  as  more  readily 
accessi bl e. 

Some  of  the  modules  will  produce  interim  (CRT  or  hard  copy)  reports  which  will 
constitute  a nearly  continuous  monitoring  of  the  paratransit  operation.  Re- 
duction of  these  data  will  produce  outputs  useful  for  every  aspect  of  para- 
transit operation  from  improving  control  data  bases  to  system  planning. 

2.5.3  Elimination  of  Existing  Deficiencies 

The  major  deficiencies  of  manual  systems  can  be  dichotomized  into  deficiencies 
within  the  control  system  itself  and  deficiencies  in  the  interfaces  with  non- 
control  elements. 

Within  the  control  system,  optimization,  at  least  to  some  extent  will  become 
possible  --  manual  systems  are  almost  totally  preoccupied  with  feasibility. 

The  essential  exponential  nature  of  the  routing/scheduling  problem  is  not 
eliminated,  but  the  manageable  size  limit  for  paratransit  systems  is 
increased.  Dispatcher  changes,  whether  by  shift  changes,  break  schedules, 
or  by  hand-offs  between  dispatchers  within  the  system,  will  be  easier  and 
less  disruptive  to  the  service. 

The  interfaces  among  all  elements  of  the  operation  will  improve  since  all  data 
elements  of  interest  will  be  explicit  and  accessible. 
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2.5.4  Improved  Timeliness 


The  response  time,  as  perceived  by  the  patron,  is  expected  to  improve.  Of 
perhaps  greater  importance  is  the  fact  that  the  quality  or  value  of  the 
response  is  "better"  (in  quality  of  service,  resource  utilization,  or  any 
other  measure  of  system  performance) , and  that  by-products  of  the  automated 
procedure  reduce  the  effort  and  time  required  for  non-control  operations 
(billing,  reporting,  etc.). 

2.5.5  Elimination  or  Reduction  of  Existing  Capabilities 

Existing  capabilities  will  not  be  reduced  by  automation.  This  is  because  of 
fall -back  requirements,  and  the  full-time  coverage  requirement.  For  some 
systems,  there  may  be  staff  reductions  possible  if: 

(1)  The  mode  of  operation  changes  (e.g.,  demand--responsi ve  to  advanced 
scheduling);  or 

(2)  A degraded  level  of  service  is  acceptable  as  fallback;  or 

(3)  Short-term,  short-notice  support  personnel  are  available  as  a 
fall-back  mode. 

2.6  SUMMARY  OF  IMPACTS 

This  section  will  be  limited  to  operations;  automated  modules  are  assumed  to 
replace  their  manual  equivalents. 

2.6.1  Equipment  Impacts 

Except  for  the  computer  hardware  itself,  no  equipment  impacts  are  envisioned. 
The  hardware  to  be  used  is  expected  to  require  no  special  site  requirements 
and  little  extra  space. 
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2.6.2  Software  Impacts 


The  software  system  is  envisioned  as  essentially  a "stand-alone"  system.  In- 
terfaces with  other  application  and  support  software  will  be  by  way  of  input- 
output.  The  software  will  be  designed  to  operate  under  a "least-common 
denominator  (either  a primitive  or  universal)  operating  system"  likely  to 
be  available  for  the  target  class  of  hardware. 

2.6.3  Organizational  Impacts 

Organizational  impacts  are  expected  to  be  minimal  except  to  the  extent  that 
better  knowledge  and  control  may  influence  policy  and/or  objectives  of  para- 
transit  management. 

2.6.3. 1 Functional  Reorganizati on 

No  major  change  is  anticipated;  in  the  long  term,  policy  and  objectives  could 
change  as  a result  of  more  efficient  operation. 

2. 6. 3. 2 Staff  Level  Changes 

The  staff  level  will  not  increase;  for  certain  situations,  there  may  be  a 
decrease  but  such  is  not  assured.  Although  the  software  will  improve  the 
productivity  in  terms  of  patrons  per  hour  for  the  system  or  vehicles  per 
controller,  the  threshold  character!' Stic  of  staffing  requirements  may  prevent 
any  control  staff  cutback.  It  is  possible  that  improved  vehicle  utilization 
may  allow  a reduction  in  the  number  of  vehi cl es/dri vers  required. 
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2. 6. 3. 3 Upgrade/Downgrade  of  Staff  Skills 


The  skills  required  for  an  automated  system  are  different  from  those  required 
for  a manual  system;  the  transition  is  more  nearly  lateral  than  upgrading  or 
downgradi ng. 

For  staff  currently  operating  a manual  system,  new  skills  are  necessary;  these 
are  of  a mechanical  nature  such  as  the  use  of  input  devices  and  interpretation 
of  CRT  displays.  Existing  staff  members  can  attain  these  skills  fairly 
quickly;  no  staff  turnover  is  anticipated.  The  functions  performed  will  be 
the  same;  the  tools  for  performing  them  will  be  improved. 

For  new  employees,  the  skills  required  for  operation  of  an  automated  system 
are  expected  to  be  acquired  more  quickly  and  easily  than  those  required  for  a 
manual  system.  The  only  staff-skill  problem  anticipated  is  that  of 
maintaining  manual  skills  when  they  are  exercised  i nf requently . The  fall  back 
mode  is  expected  to  be  manual  operation. 

2.6.4  Operational  Impacts 

2. 6. 4.1  Staff  and  Operational  Procedures 

The  functions  to  be  performed  are  nominally  direct,  one-to-one  replacements 
for  functions  now  performed  manually.  Direct  impact  on  staff  and  procedures 
is  therefore  minimal;  procedural  changes  are  essentially  at  the  mechanical 
1 evel . 
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In  the  long  term,  the  existence  and  accessi bi 1 ity  of  better  information  may 
lead  to  changed  policies,  goals,  and  objectives  of  paratransit  operation.  Al- 
though such  changes  can  be  expected,  their  nature  cannot  be  predicted. 

2. 6.4. 2 Relations  Between  the  Operating  Center  and  Its  Users 

Two  classes  of  user  must  be  considered.  For  both  classes,  the  automation  will 
not  be  perceived  as  a structural  change.  Users  are  interested  in  their  input 
to  the  system  and  in  their  output  from  the  system.  Whether  the  outputs  are 
generated  from  an  automated  system  or  the  reading  of  tea  leaves  is  irrelevant. 

For  both  the  patron  user  and  sponsori ng/support i ng  agency  users,  the  input 
side  will  remain  as  it  is  in  a manual  system.  For  both  classes,  information 
outputs  will  be  at  least  as  good  in  terms  of  detail  and  frequency,  and  better 
in  terms  of  accuracy,  reliability,  and  timeliness. 

For  the  patron,  the  quality  of  service  is  expected  to  improve;  for  the  para- 
transit agency,  resource  utilization  will  improve. 

2. 6.4. 3 Procedures  of  the  Operating  Center 

For  a dedicated  equipment  configuration,  no  existing  computer  services  will  be 
impacted.  For  the  time-sharing  or  batch  environment,  the  patron  acquisition, 
file  management,  and  routing/scheduling  functions  are  expected  to  appear  to  be 
exactly  like  other  users.  These  functions  present  neither  peculiar,  esoteric, 
nor  especially  stringent  requirements. 


2. 5.4.4  Data 


Data  are  described  more  completely  in  Chapters  5 and  5.  The  major  impact 
perceived  is  that  many  data  elements  now  implicit  will  be  organized, 
formatted,  and  stored  explicitly.  Many  items  (e.g.,  vehicle  speeds,  travel 
times,  expected  schedules,  geocodes,  etc.)  which  now  never  appear  in  any  sort 
of  physical  file  will  be  stored  explicitly  and  amenable  to  retrieval  and 
systematic  manipulation. 

The  sources  for  basic  input  data  will  continue  to  be  primarily  the  patron  and 
the  sponsoring  agency.  The  only  additional  source  foreseen  is  the  output  from 
the  system  itself.  Several  files  are  prerequisite  to  an  operational  system: 

(1)  a patron  eligibility  Tile;  and 

(2)  a geocoding  file. 

Neither  of  these  files  poses  an  undue  start-up  cost,  and  both  will  be  amenable 
to  "friendly"  updates,  extensions,  and  refinements. 

2. 6.4. 5 Data  Retention  and  Retrieval 

Data  retention  and  retrieval  procedures  will  be  quite  conventional.  The 
static  lot  i Vise  will  not  be  modified  during  real-time  operations.  Dynamic 
data  will  be  maintained  for  only  a short  period  of  time;  there  is  no  necessity 
for  wholesale  inserting  of  dynamic  data  into  the  static  base.  Interim  data 
will  be  of  a throw-away  type. 
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2. 6. 4. 6 Reporting  Methods 


Reporting  will  be  both  more  detailed  and  more  systematic  than  with  a manual 
system.  These  reports  will  include  hard-copy  and  machine  readable  media; 
recipients  of  the  reports  include  other  modules  of  the  control  system,  control 
system  staff,  non-control  staff  management,  sponsoring  agencies,  and  UMTA. 

2. 6.4. 7 System  Failure  Consequences  and  Recovery  Procedures 

There  appears  to  be  no  particular  difficulty  in  controlling  vehicles  while  the 
system  is  down.  There  are  several  reasonable  modes  appropriate  for  different 
types  of  paratransit: 

(1)  If  the  level  of  personnel  has  remained  fixed,  the  control  can 
revert  to  the  manual  system; 

(2)  If  the  staff  has  been  reduced,  a degraded  mode  of  operation  must  be 

defined.  These  degraded  modes  are  not  part  of  the  software;  they 
might  include  some  or  all  of  the  following:  (1)  accepting  no  new 

patrons,  (2)  retrograding  to  a check  point  system;  (3)  allowing  only 
subscription  patrons;  or  (4)  retrograding  into  a fixed  schedule 
system. 

The  transition  from/to  a manual  to/from  an  automated  system  is  extremely 
difficult.  The  essential  problem  is  that  transition  to/from  manual  from/to 
automated  implies  that  all  data  elements  must  exist  in  parallel  in  both  a 
machine-readabl e form  and  in  a human-readable  form.  For  the  automated  to 
manual  transition,  a hierarchical  checkpointing  system  in  which  the  level', 
vary  from  a single  transaction  to  projected  routes  and  schedules  for  all 
vehicles  should  prove  acceptable. 
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For  the  restart  of  the  automated  system,  the  problem  is  intrinsically  more 
difficult;  any  workable  procedure  is  expected  to  include  degraded  operations 
for  an  extended  period  of  time.  Section  3.5.3  discusses  several  alternative 
approaches. 

2. 6. 4. 8 Data  Input  Procedures 

Data  input  for  any  specific  configuration  of  modules  will  be  conventional. 

The  sources  may  be  hard-copy,  oral,  or  machine-readable.  Entry  is  expected  to 
be  by  keyboard,  tape,  disc,  or  anal og-to-di gital  device.  Data  transfer  among 
modules  will  be  conceptually  input-output. 

2. 6.4. 9 Computer  Processing  Time  Requirements 

For  off-line  modules,  time  is  less  important  than  cost;  for  other  modules,  the 
automation  is  expected  to  result  in  improved  timing. 

2.7  COST  CONSIDERATIONS 

To  a great  extent,  cost  considerations  are  dominant  in  the  system  proposed. 

In  general  terms,  the  goal  is  to  accomplish  as  much  as  is  reasonable  with 
acceptable  total  cost  while  retaining  maximum  portability.  Features  of  the 
proposed  system  which  are  almost  totally  dictated  by  cost  considerations 
i ncl ude: 

(1)  Modularity  (automated  and  manual); 

(2)  Fall-back  procedures; 

(3)  Implicit  street  networks; 
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(4)  No  additional  communication  requirement;  and 

(5)  Accommodation  of  different  hardware-software  environments  by 
module. 

Start-up  costs  for  data  base  construction  and  training  must  be  kept  relatively 
small.  The  modularity  of  automated  functions,  mapping  one-to-one  to  presently 
used  manual  functions,  should  be  very  valuable  in  this  area.  Operating  staff 
will  require  training  only  in  new  mechanical  skills;  the  functions  performed 
are  equivalent  in  an  input-output  sense  to  those  currently  performed  manually. 


In  general,  these  characteristics  which 
center,  impose  additional  but  tolerable 
acceptable  trade-off  since  there  is  one 
tional  centers. 


are  very  nice  for  the  operational 
burdens  upon  development;  this  is  an 
developer  but  a large  number  of  opera 
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3.  REQUIREMENTS 
3.1  FUNCTIONS 


In  qualitative  terms,  the  system  is  to  include  modules  which  replace  manual 
functions  wherever  such  replacement  will  be  cost-effective,  whether  such  cost- 
effectiveness  is  in  terms  of  the  control  cost  or  overall  paratransit  operation 
cost. 


Different  classes  of  the  modules  have  different  sorts  of 
the  configuration  and  environment  may  be  different.  The 
are  described  briefly  in  ascending  order  of  initial  cost 
within  each  configuration  are  also  described. 


requirements;  even 
possible  environments 
Modules  exercisable 


3.1.1  Type  A System 

This  system  requires  only  a batch  mode  of  operation;  response  times  can  be  in 
hours.  The  response  time  requirement  can  be  met  by  a service  bureau  overnight 
operati on. 

For  a completely  off-line  configuration,  hereafter  called  Type  A,  no  real-time 
or  direct  control  functions  are  possible.  The  major  control  function  to  be 
performed  is  advanced  routing  and  scheduling.  Other  modules  related  directly 
to  control  functions  will  consist  of  procedures  which  support  the  optimization 
algorithm  in  a pre-processi ng  or  post-processing  sense.  Major  modules  will  be 
patron  acquisition  (from  a patron  eligibility  file),  calculation  of  estimated 
speeds  and  travel  times,  generation  of  reports  for  control  staff,  and 
generation  of  trip  itinerary  reports  for  the  vehicles.  Updating  of  static  and 
dynamic  files  must  also  be  performed;  static  files  will,  in  general,  be 
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modified  by  inputs  not  related  to  the  control  process;  dynamic  files  by 
monitoring  of  system  performance  relative  to  its  predicted  performance. 

3.1.2  Type  B System 

This  system  requires  interactive  access;  the  response  time  must,  for  some 
functions  at  least,  be  much  shorter  than  that  which  is  required  for  the  Type  A 
system.  This  requirement  can  be  met  by  a time-shared  (with  other  users) 
system. 

A non-dedicated  on-line  system,  hereafter  called  Type  B,  will  include  all  of 
the  functions  of  a Type  A system,  but  again  will  not  contain  any  real-time 
control  functions.  It  will  have  additional  modules  for  patron  acquisition 
(for  patron  eligibility  and  patron  service  request)  via  on-line  data  entry,  a 
"friendly"  geocoding  system,  and  a more  comprehensive  reporting  capability. 

The  additional  reporting  capability  is  primarily  the  detailed  patron  request 
augmented  by  geocodes,  travel  times,  speeds,  etc.;  and  hard-copy  aids  which 
approximate  the  manual  aids  now  in  use  (maps,  tickler  boards,  etc.). 

3.1.3  Type  C System 

This  system  requires,  for  some  functions,  very  short  response  time.  A 
dedicated  system  or  high  priority  use  of  a time-shared  system  is  necessary. 

A dedicated  on-line  or  real-time  system,  a Type  C system,  will  include  all  of 
the  Type  B functions  plus  functions  for  real-time  routing  and  scheduling.  The 
extensions  are  based  on  the  real-time  monitoring  capability.  Vehicle  location 
will  be  tracked  by  stop,  patrons  will  be  acquired  for  assignment  as  a function 
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of  time,  all  transactions  will  be  logged.  If  assignment  is  automated,  a feas- 
ible or  most  nearly  feasible  (with  respect  to  desired  level  of  service)  as- 
signment will  be  sought.  Any  optimization  will  be  completely  local. 

The  real-time  reports  will  look  very  much  like  the  Type  B reports  except  that 
they  represent  observed  status  as  well  as  projected  status  of  the  system. 

They  also  include  Type  B reports  whose  element  selection  is  based  on  user 
supplied  truth  tables.  These  reports  will  be  used  for  two  purposes.  The 
first  is  as  an  alert  to  the  operator;  this  is  a warning  as  to  occurrence 
(actual  or  imminent)  of  some  abnormal  event  - perhaps  an  unacceptably  large 
schedule  slippage.  The  second  use  is  as  a basis  for  manual  fall  back;  one 
report  is  a snapshot  of  the  current  system  state  and  will  be  produced 
periodi cal  ly. 

Output  from  all  system  types  must  be  amenable  to  reduction,  summaries,  etc., 
for  non-control  functions  as  well  as  control  functions. 

3.2  PERFORMANCE 

Performance  requirements  will  be  different  for  Type  A,  B,  and  C systems  or 
more  precisely,  for  the  functions  included  in  Type  A only,  Type  B not  in  Type 
A,  and  Type  C not  in  Type  B.  The  specific  performance  requirements  will  be 
factored  into  those  for  each  type  of  control  system. 

3.2.1  Accuracy 

Accuracy  requirements,  in  a computational  sense,  are  not  terribly  stringent. 
For  locations,  a quarter-mile  error  is  acceptable.  For  travel  times  and 
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speeds,  the  objective  is  to  obtain  the  best  possible  subject  to  data 
limitations,  and  the  fact  that  explicit  representations  of  the  street  network 
is  to  be  avoided.  The  accuracy  attained  should  be  as  good  as  is  required;  an 
important  characteristic  is  that  the  system  be  workable  even  with  relatively 
poor  data.  In  an  accounting  context,  or  in  the  sense  that  no  transaction  be 
lost  or  garbled,  accuracy  is  extremely  important. 

Precision  of  computation  is  again  not  especially  demanding.  Probably  as  much 
as  90  to  95  percent  of  the  required  calculations  can  be  performed  with  fixed 
point,  sixteen  bit  arithmetic. 

3.2.2  Validation 

Static  data  bases  will  require  some  (off-line)  validation  procedures.  These 
are  not  foreseen  as  particularly  demanding;  they  are  expected  to  accompany 
data  base  updating.  Validation  will  consist  mostly  of  "matching"  and  "rang- 
ing." 

Dynamic  and  interim  data  bases,  for  the  most  part,  will  be  generated  via  a 
"prompting"  mode  of  operation.  Thus,  within  the  automated  modules,  dynamic 
and  interim  data  will  be  as  good  as  the  static  data  base  except  for  hardware 
failure.  Except  for  a completely  automated  system,  every  data  element  passed 
from  module  to  module  will  appear  to  operating  personnel  in  readable  form. 

The  routine  application  of  "laugh"  tests,  although  external  to  the  automated 
modules,  should  eliminate  most  errors  which  would  result  in  grossly  bad 
routing  or  scheduling. 
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3.2.3  Timing 


3. 2. 3.1  Response  Time 

Response  time  is  not  at  all  important  for  Type  A functions;  overnight  or  even 
weekly  turnaround  should  be  adequate.  Cost  is  much  more  important. 

For  Type  B and  Type  C functions  response  time  is  important,  but  the 
requirements  are  quite  different.  For  Type  B functions,  which  can  be 
time-shared,  the  interim  or  dynamic  data  generated  will  maintain  their 
usefulness  in  spite  of  poor  response  time  except  in  a request  for  immediate 
service.  Good  response  time  will  not  improve  fleet  performance;  it  will 
improve  the  efficiency  of  personnel  and  provide  convenience  to  the  patron. 

For  Type  C functions,  the  interim  or  dynamic  data  will  lessen  in  quality,  ac- 
curacy, and  relevance  with  the  passage  of  time  after  initiation  of  computa- 
tion. Thus,  poor  response  time  will  degrade  the  entire  paratransit  operation. 

3. 2. 3. 2 Data  Transfer  and  Transmission  Time 

For  Type  A systems,  there  is  essentially  no  time  constraint.  For  Type  B and 
Type  C systems,  the  most  stringent  requirement  is  for  modul e-to-modul e 
transfer  of  information  where  either  or  both  modules  may  be  automated. 
Generally,  there  will  be  less  data  transmission  i ntermodularly  than 
i ntramodul arly.  The  target  class  of  hardware  should  be  quite  acceptable. 
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3. 2. 3. 3  Throughput  Time 


There  is  basically  no  throughput  requirement.  For  Type  A systems,  cost  is 
much  more  important;  while  for  Types  B and  C,  which  are  real-time,  throughput 
measures  are  totally  irrelevant;  response  time  is  the  appropriate  criterion. 

3.2.4  Flexibility 

Flexibility  of  the  system,  or  the  amenability  of  the  system  to  change  as  re- 
quirements change,  is  assumed  by  the  very  concept  of  the  modular  approach.  A 
change  in  requirements  over  time  is  no  different  from  separate  requirements 
for  different  systems. 

3.3  INPUTS-OUTPUTS 

For  this  application,  intermodular  data  transfer  is  perceived  as  either  addi- 
tional input,  output,  or  as  very  precisely  defined  interfaces.  These 
inter-modular  i nputs-outputs  will  be  described  in  detail  in  the  appropriate 
System/Subsystem  Specification.  It  is  necessary  to  consider  these  interfaces 
as  i nputs-outputs  because  of  the  automated-manual  nature  of  the  modules. 
Interfaces  between  modules  are  interim  data  bases  if  both  modules  are 
automated  but  must  be  considered  as  i nputs-outputs  if  the  one  module  is 
automated  and  the  other  manual.  Several  media  and  various  formats  will  be 
accommodated  in  terms  of  i nputs-outputs  for  the  hybrid  system. 

3.4  DATA  CHARACTERISTICS 

Data  characteristics  are  described  in  Chapters  5 and  6. 
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3.5  FAILURE  CONTINGENCIES 


For  Type  A functions,  no  unusual  procedures  are  required.  The  remainder  of 
this  section  will  be  concerned  with  Type  B and  Type  C functions. 

3.5.1  Back-Up 

Within  the  target  configurations,  there  will  be  little  or  no  hardware 
redundancy.  Extra  tape  drives,  disc  drives,  CRT's,  etc.,  may  well  be 
available  and  usable  for  back-up;  files  for  back-up  will  be  via  a grandfather 
file  technique.  However,  any  hardware  redundancy  is  expected  to  consist  of 
substitution  of  functionally  equivalent  systems  or  subsystems.  It  is  not 
required  that  the  system  be  reconfi gurable  if  components  go  down.  No  degraded 
modes  of  operation  are  required. 

3.5.2  Fall-back 

The  fall-back  procedures  are  essenti al ly  the  procedures  now  being  used.  This 
is  a major  reason  for  the  transparency  requirements.  Fail-back  to  manual 
operations  will  inevitably  result  in  a degraded  efficiency  or  quality  of 
service  provided.  The  software  will  generate  reports  at  checkpoints 
periodically  and  log  subsequent  transaction  information.  There  will  be  a 
hierarchy  of  such  checkpoints;  these  are  to  provide  a bridge  between  automated 
and  manual  operation. 

3.5.3  Recovery  and  Restart 

This  is  the  most  difficult  requirement  of  the  entire  system.  There  is  no  ob- 
vious way  to  recover  and  restart  that  is  even  close  to  being  sati sfactory . 
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The  essential  problem  is  that  rather  large  masses  of  data  must  be  entered  very 
quickly;  much  of  this  exists  only  in  an  implicit  and  unformatted  form  in  manu- 
al operation. 


Several  alternatives  are  to  be  explored;  these  include  but  are  not  limited  to: 


(1)  Phased  restart  This  strategy  would  involve  bringing  modules  "up"  in 
a predetermined  sequence  (i.e.,  a scheme  whereby  the  automated 
modules  restart  in  a prescribed  order). 

(2)  Cycled  restart  This  strategy  involves  a transition  to  automated 
operation  by  vehicle  or  some  subfleet  of  vehicles. 

(3)  Resurrected  restart  This  strategy  updates,  from  the  last  checkpoint 
before  failure,  by  entering  each  subsequent  transaction  accomplished 
manually.  This  could  be  done  via  parallel  recording  of  transactions 
on  some  batch  loadable  medium. 

(4)  Generalized  representation  This  strategy  would  use  generalized  or 
summary  information  to  synthesize  a current  status  representative  of 
(in  the  most  important  characteri sties)  the  true  status. 
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4.  OPERATING  ENVIRONMENT 


The  environment  can  vary  greatly  depending  mostly  on  the  control  system  type. 
Characteristics  and  objectives  of  the  paratransit  system  also  have  a strong 
influence,  but  much  of  this  influence  will  be  considered  in  the  selection  of 
system  type. 


4.1  TYPE  A SYSTEM 


4.1.1  Equipment 

No  new  ADP  equipment  is  required  for  the  control  site  per  se.  The  entire  sys- 
tem requires  only  a service  bureau  type  of  operation.  Requirements  are  thus 
access  to  rather  than  control  of  the  ADP  resources  described. 

4. 1.1.1  Processor  and  Size  of  Internal  Storage 

The  prototype  routing  scheduling  procedure  is  written  in  FORTRAN  77,  and  is 
executable  on  the  UNIVAC  1100  series  computer.  For  an  8-vehicle,  85-patron 
system,  it  will  run  in  65K  of  core  in  about  5 minutes.  Since  this  program  is 
a prototype  with  known  inefficiencies  with  respect  to  both  storage  and  time, 
the  numbers  cited  can  be  considered  an  upper  bound  on  processor  resources. 
Nearly  all  of  the  calculations,  for  example,  can  be  performed  with  16-bit, 
fixed  point,  single  precision  arithmetic.  The  advanced  routing/scheduling 
modules  are  expected  to  be  the  most  demanding  with  respect  to  computation  and 
internal  storage.  Other  modules  are  expected  to  be  much  less  computational ly 
i ntensi ve. 
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4. 1.1.2  Storage,  On-Line  and  Off-Line,  Media,  Form,  and  Devices 


Good  quality  hard  copy  reports  should  be  provided.  Except  for  these,  the 
storage,  media,  and  devices  are  the  responsibility  of  the  service  bureau. 

4.1.2  Support  Software,  Interfaces,  Security,  and  Privacy 
No  particular  problems  are  foreseen  in  these  areas. 


4.2  TYPE  B SYSTEM 


4.2.1  Equipment 

The  Type  B system  is  on-line  but  may  or  may  not  utilize  a dedicated 
confi guration. 

4. 2. 1.1  Processor  and  Size  of  Internal  Storage 


Major  data  bases  will  be  of  the  unit-record  type  based  on  patron  (eligibility, 
dispatcher  inventory  and  assignment  status),  based  on  piecewise  linear  street 
segments,  based  on  place  names,  and  based  on  landmarks.  Each  of  these  static 
data  records  will  be  of  the  order  of  100  characters.  Since  all  static  data 
are  potentially  required  in  the  patron  acquisition  process,  all  must  be 
accessible  within  a few  seconds.  If  the  system  is  time-shared,  almost  any 
commercial  time-sharing  system  is  internally  as  powerful  as  necessary  in  both 
time  and  storage. 
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If  the  system  is  micro-based,  the  targeted  price  class  of  hardware  should  be 
more  than  adequate  if  the  operational  mode  is  compilation  rather  than 
i nterpretati on. 

4. 2. 1.2  Storage,  On-Line  and  Off-Line,  Media,  Form,  and  Devices 

Whether  time-shared  or  dedicated,  there  is  a requirement  for  a substantial  on- 
line storage  capability.  Although  supporting  software  for  updating  the  data 
bases  is  to  be  provided,  updating  can  be  relatively  slow;  it  is  not  necessari- 
ly done  in  real  time.  Internally  generated  data  will  be  orders  of  magnitude 
less  in  terms  of  size  but  will  have  about  the  same  response  time  requirement. 
Conventional  hard  disk  characteristics  are  more  than  adequate  for  both 
functi ons. 

Off-line  storage,  except  for  back-up  of  on-line,  poses  no  demanding  volume  or 
response  time  requi rements ; it  must  exist  but  can  be  relatively  slow.  It  may 
be  floppy  disk  and/or  cassette. 

4. 2. 1.3  Input-Output  Devices 

Whether  dedicated  or  time-shared,  input-output  requirements  will  be  quite 
similar.  The  patron  acquisition  procedure  is  conceived  as  operating  in  a 
prompting  mode;  CRT  terminal  devices  will  be  the  busiest  input-output 
components.  The  output  (CRT)  side  is  several  orders  of  magnitude  greater  than 
input  (keyboard).  A moderate  speed  hard  copy  device  is  also  required;  this 
could  be  a line  printer  or  CRT  copy  device. 


34 


4. 2. 1.4  Data  Transmission  Devices 


No  transmission  is  involved  except  between  the  terminal  and  the  CPU. 

4.2.2  Support  Software,  Interfaces,  Security,  and  Privacy 

With  a time-shared  system,  the  applications  program  must  conform  to  the  com- 
puter center  requirements.  Applications  must  be  based  on  a least-common- 
denominator  philosophy  insofar  as  is  feasible. 

For  a dedicated  system,  at  least  a primitive  operating  system  is  expected. 

File  handling  must  be  rather  good;  it  may  be  attained  by  raw  hardware 
capability,  operating  system,  or  operating  system  augmenting  application 
programmi  ng. 

Interfaces,  privacy,  and  security  do  not  appear  to  pose  any  limiting  require- 
ments. 

4.3  TYPE  C SYSTEM 

This  has  much  the  same  appearance  as  a dedicated  Type  B system.  The 
additional  processing  is  primarily  of  the  transaction  type.  The  configuration 
must  support  an  additional  terminal  for  each  dispatcher,  be  capable  of 
producing  interim  reports,  and  performing  patron  insertion  into  vehicle 
itineraries;  the  last  function  is  to  be  at  least  feasible;  and  at  most, 
locally  optimized. 
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5.  DATA  DESCRIPTION 


The  data  are  described  in  this  section  as  being  in  files.  The  term  "files"  in 
this  context  implies  that  the  software  has  access  to  the  content  indicated. 
There  is  no  intent  to  represent  every  data  element  in  exactly  the  form  in 
which  it  will  appear  physically  in  terms  of  formats,  indices,  pointers,  etc., 
nor  is  there  any  implication  of  file  structure  in  the  computer  science  sense. 

5.1  STATIC  DATA 

Data  are  considered  static  if  they  are  not  subject  to  modification  by  the 
processes  of  patron  assignment  to  a vehicle  or  vehicle  control.  Static  data 
are  used  in  a read  only  mode  insofar  as  the  control  process  is  concerned. 
Updating  is  assumed  to  be  periodic  and  does  not  have  to  be  performed  online. 
For  most  of  the  static  files  there  will  be  an  internally  generated  parallel 
file  containing  the  entities  captured,  corrected,  or  marked  for  purging  since 
the  last  periodic  update.  The  form  of  data  is  indicated  by  element  with  T for 
free  form  text  or  F for  formatted. 

5.1.1  El  igibi lity  File 

This  file  is  required  for  paratransit  systems  in  which  patrons'  eligibility 
must  be  formally  established,  and  for  systems  in  which  some  part  of  the  cost 
is  borne  by  some  other  agency.  The  file  is  optional  in  other  cases;  it  would 
be  useful  if  there  are  a large  fraction  of  habitual  users.  The  file  is 
accessed  by  the  receiver  of  the  request  for  service. 
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The  file  entity  is  the  patron;  data  elements  are: 


(1)  Name  (T); 

(2)  Identification  (F); 

(3)  Home  Address  (T); 

(4)  Geocode  (F); 

(5)  Telephone  (F); 

(6)  Address  Prefix  (F  and  T); 

(7)  Sponsoring  Agency  (T); 

(8)  Billable  Agency  (F); 

(9)  Starting  Date  (F); 

(10)  Ending  Date  (F); 

(11)  Destination  (F  and  T); 

(12)  Destination  Geocode  (F); 

(13)  Class  (F  and  T). 


5.1.2  Subscription  File 

This  file  is  accessible  to  the  dispatcher  on  demand,  and  to  the  software  as  a 
function  of  real  time.  Dependent  upon  the  paratransit  system,  it  may  replace 
or  augment  the  eligibility  file. 

The  file  entity  is  the  patron;  the  data  elements  are: 

(1)  Name  (T); 

(2)  Identification  (F); 

(3)  Home  Address  (T); 

(4)  Geocode  (F); 

(5)  Telephone  (F); 

(6)  Address  Prefix  (F  and  T); 
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(7)  Sponsoring  Agency/Authorization  (T); 

(8)  Bi liable  Agency  (F ) ; 

(9)  Starting  Date  (F); 

(10)  Ending  Date  (F); 

(11)  Destination  (F  and  T); 

(12)  Destination  Geocode  (F); 

(13)  Class  (F); 

(14)  Frequency  Code  (F ) ; 

(15)  Pick-up  Time/Code  (F);  and 

(16)  Return  Time/Code  (F); 

5.1.3  Address  Di rectory  Files 

Street  addresses  are  used  as  input  to  produce  geocodes  in  two  slightly 
different  ways.  For  either  case,  the  street  address  may  have  a prefix 
denoting  community  within  transit  area.  Short  streets  will  be  considered  as 
points;  a short  street  is  one  which  has  a total  length  of  a half  mile  or 
1 ess. 


5. 1.3.1  Short  Streets 

The  file  entity  is  the  street;  the  data  elements  are: 

(1)  Prefix  (optional)  (F); 

(2)  Street  Name  (T);  and 

(3)  Geocode  (F). 
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5. 1.3. 2 Long  Streets 


Long  street  addresses  are  geocoded  by  linear  interpolation  of  a piecewise 
linear  segment  representation  of  the  street.  The  entity  is  the  line  segment; 
the  elements  are: 

(1)  Prefix  (F), 

(2)  Lowest  Number  (F)  (includes  modifier  such  as  N,  S,  etc.); 

(3)  Geocode  for  Number  (F);  and 

(4)  Street  Name  (T)  (First  Only). 

5.1.4  Landmark  Directory 

For  a paratransit  system  which  is  many-few,  either  de  facto  or  by  policy,  a 
geocoding  shortcut  is  provided.  For  commonly  used  end  points  a special  short 
code,  probably  three  characters,  is  used  for  geocoding.  These  short  codes 
will  be  selected  by  the  user;  they  could  be  mnemonic,  acronymns,  or  structured 
in  some  consistent  way  (H  for  hospital,  M for  shopping  mall,  etc.).  Check- 
points could  be  used  interchangeably  with  landmarks  or  could  be  in  a similar 
parallel  file.  Use  of  this  scheme  avoids  the  prompting  mode  required  for  the 
other  schemes  and  minimizes  I/O.  The  cost  is  that  the  operator  must  Tiemorize 
the  landmark  codes.  The  file  entities  are  landmarks  (checkpoints);  the  data 
elements  are: 

(1)  Code  (F); 

(2)  Geocode  (F);  and 

(3)  Name  (T). 
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5.1.5  Place  Name  Directory 

This  directory  accommodates  places  which  are  not  commonly  located  by  street 
address  but  are  not  used  frequently  enough  to  be  considered  landmarks.  Places 
such  as  schools,  stores,  minor  shopping  centers,  etc.,  are  included. 

Reference  is  by  place  name  and  execution  is  in  the  prompting  mode.  The  file 
entities  are  the  places;  the  data  elements  are: 

(1)  Place  name  (T); 

(2)  Geocode  (F);  and 

(3)  Street  Address  (F). 

5.1.6  Segment  Speed  File 

This  file  is  used  to  calculate  an  estimated  segment  speed.  These  speeds  will 
be  used  in  making  "good"  patron  assignments  to  vehicles.  This  file  could  be 
replaced  and/or  augmented  for  some  paratransit  operations.  As  examples,  a 
checkpoint  system  might  store  point-to-point  travel  times  explicitly;  the 
transit  area  might  be  sufficiently  homogeneous  with  respect  to  attainable 
speed  that  travel  times  can  be  calculated  to  required  accuracy  as  a function 
of  euclidean  or  rectilinear  distance. 

Two  slightly  different  files  seem  equally  appropriate  at  this  time.  In  each 
case  the  entity  is  a zone. 

5. 1.6.1  First  Alternate  Scheme 

This  method  minimizes  on-line  computation  time  but  requires  more  storage  and 
more  complex  updating  procedures.  The  entity  is  the  zone;  the  data  elements 
are: 
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(1)  Origin  Geocode  (F); 

(2)  First  Destination  Geocode  (F); 

(3)  0-D  Attainable  Speed  (F); 

(4,5)  As  (2)  and  (3)  for  Second  Destination  Zone;  and 
(2n,2n+l)  As  (2)  and  (3)  for  nth  Destination  Zone. 

The  zone  is  simply  a rectangular  area  defined  by  its  maximum  and  minimum 
coordi nates. 

5. 1.6.2  Second  Alternate  Scheme 

This  scheme  has  the  advantages  of  minimizing  storage  requirements  and  updating 
complexity,  and  provides  for  alternative  point-to-point  paths;  these 
characteristics  are  attained  at  the  expense  of  more  on-line  computation.  The 
file  entity  is  the  zone;  the  data  elements  are: 

(1)  Geocode  (F)  (minimum  coordinates);  and 

(2)  Attainable  Speed  Within  Zone  (F). 

5.1.7  Mi  nor  Files 

There  are  several  other  files  which  may  or  may  not  be  required  for  particular 
paratransit  systems. 

5. 1.7.1  Vehicl e Files 

One  or  more  files  may  exist  with  vehicles  as  entities.  These  could  contain 
control  data  as  capacity,  special  equipment  such  as  lifts,  etc.  They  coul  i 
also  contain  information  which  is  primarily  for  noncontrol  operations  but  V 
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marginal  utility  to  control  such  as  preventive  maintenance  schedules;  these 
data  could  be  used  to  explicitly  accommodate  noncontrol  constraints  into  the 
control  process. 

5. 1.7.2  Nominal  Schedules 

For  either  subscription  service,  or  service  with  many  recurring  trips,  it  may 
prove  advantageous  to  use  a previously  exercised  itinerary  as  a prototype; 
this  can  be  modified  initially  by  deleting  non-holdover  patrons.  Patrons  may 
then  be  inserted  to  an  existing  itinerary  using  procedures  which  are  certainly 
less  complex  and  probably  more  nearly  optimal  per  computation  dollar. 

5. 1.7.3  Mi  seel  1 aneous 

There  will  be  a number  of  miscellaneous  data  elements  whose  parent  entities 
are  not  clearly  defined.  These  data  primarily  relate  to  noncontrol  activities 
but  may  impose  constraints  upon  the  control  process.  Some  examples  are: 

(1)  Vehicle  Availability  by  Time; 

(2)  Personnel  Resources  by  Time;  and 

(3)  Required  Locations  for  Fueling,  Lunch  Breaks,  etc. 

5.2  DYNAMIC  INPUT  DATA 

The  basic  concept  of  system  operation  is  to  minimize  the  data  actually  input. 
Instead  the  dynamic  data  is,  insofar  as  is  practicable,  to  be  selected  from 
static  data.  Since  the  software  is  to  operate  in  a prompting  mode,  the  intent 
is  to  minimize  the  number  of  key  strokes  required  to  select  from  and  augment 
as  necessary  static  data  to  construct  dynamic  data. 
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Aside  from  the  initialization  or  start-up  procedures,  which  may  require  expli- 
cit input,  the  data  entered  will  be  for  patron  acquisition,  for  patron  assign- 
ment, or  for  system  monitoring.  The  actual  inputs  are  mostly  keys  to  initiate 
procedures  or  parameters  for  use  by  the  procedures  generated. 

5.2.1  Dispatcher  Inventory  File 

Entities  in  this  file  are  the  patrons  to  be  served  within  some  specified  time 
horizon.  The  file  entries  are  constructed  by  an  individual  request  for 
service  or  by  clock  time  controlled  generation  from  the  subscription  file. 

The  elements  are: 

(1)  Name  of  Patron  (T); 

(2)  Origin  Prefix  (F); 

(3)  Origin  Address  (T); 

(4)  Origin  Geocode  (F); 

(5)  Destination  Address  (T); 

(6)  Destination  Geocode  (T); 

(7)  Class  (F); 

(8)  Time/Code  (F);  and 

(9)  Minimum  Travel  Time  (F). 

5.2.2  Dispatcher  Assignment  File 

This  is  very  much  like  the  Dispatcher  Inventory  File  except  that  its  entities 
represent  patrons  who  either  have  been  assigned  or  must  be  assigned  to  a ve- 
hicle within  a fairly  short  time  interval.  It  is  accessible  only  to  the  dis- 
patchers. The  data  elements  are: 
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(1)  Name  of  Patron  (T); 

(2)  Origin  Prefix  (F); 

(3)  Origin  Address  (T); 

(4)  Origin  Geocode  (F); 

(5)  Destination  Address  (T); 

(6)  Destination  Geocode  (F); 

(7)  Class  (F); 

(8)  Time/Code  (F); 

(9)  Minimum  Travel  Time  (F); 

(10)  Vehicle  Assignment  (F); 

(11)  Expected  Pick-up  Time  (F); 

(12)  Actual  Pick-up  Time  (F);  and 

(13)  Expected  Destination  Time  (F). 

5.3  DYNAMIC  OUTPUT  DATA 

Dynamic  output  data  are  defined  to  be  those  data  which  must  be  accessible 
during  some  part  of  an  operational  cycle  but  which  have  no  residual  value. 
The  intrinsic  value  of  the  entire  file  becomes  zero  at  the  end  of  the  opera- 
tional cycle;  individual  entities  or  elements  may  become  superfluous  as  a 
function  of  time  or  occurrence  of  some  event  during  the  operational  cycle. 
These  files  may  be  considered  as  interim  files. 
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5.3.1  Vehicle  Status  Files 


For  ease  of  exposition,  a separate  file  is  assumed  for  each  vehicle.  This 
file  contains  all  vehicle  information  relevant  to  the  dispatcher.  The 
entities  are  all  stops  related  to  on  board  patrons,  assigned  patrons,  or 
patrons  pre-schedul ed  for  a dispatching  time  horizon.  It  is  used  to  generate 
interim  reports  for  check  pointing,  monitoring,  or  aiding  in  manual 
assignment.  The  data  elements  are: 

(1)  Stop  Time  (F); 

(2)  Patron  Index  (F); 

(3)  Geocode  (F); 

(4)  Stop  Purpose  (F); 

(5)  Patron  Disutility  (F);  and 

(6-n)  Repeat  of  (1)  - (5)  for  all  other  pertinent  stops. 

5.3.2  Check  Point  Files 

The  precise  information  required  for  a check  point  or  restart  is  not  yet 
fixed.  Several  alternative  procedures,  discussed  in  Section  3.5, 
must  be  explored.  These  files  are  therefore  discussed  qualitatively  in  terms 
of  the  functions  these  data  must  support.  Some  set  of  hard  copy  files  must  be 
created  periodically;  these  must  expedite  both  the  transition  to  manual 
operation  and  restart  procedures. 

To  the  extent  that  there  is  functional  redundancy  present  within  the  configur- 
ation, alternate  medium  backups  should  be  provided.  The  backup  is  to  be  lim- 
ited to  a more-or-less  direct  substitution;  no  reconfiguration  is  expected. 
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The  checkpoint  procedure  is  to  be  hierarchical  in  the  sense  that  it  should 
provide  a good  global  snapshot  of  the  system  at  checkpoints  with  interim 
information  at  one  or  more  echelons  between  checkpoints.  These  interim 
outputs  should  provide  reasonable,  with  respect  to  time  and  complexity,  cross 
walks  to  current  system  status  for  the  transition  to  manual  operation. 

5.3.3  Report  Files 

These  reports  are  those  used  within  the  control  process.  They  may  be  hard- 
copy or  CRT  and  may  be  digital  or  graphic.  Whether  or  not  the  bases  for  the 
reports  exist  as  distinct  files  or  the  reports  generated  from  the  static  dyna- 
mic, or  internally  generated  files  directly,  is  an  open  question.  Two  sorts 
of  reports,  both  analagous  to  present  manual  aids  are  envisioned;  other  sorts 
are,  of  course,  not  precluded.  For  each  type  described,  certain  Boolean  func- 
tions are  to  be  provided  in  the  report  selection  keys.  Reports,  in  particu- 
lar, are  to  be  produced  by  time  interval,  by  vehicle,  by  patron  class,  etc., 
and  by  Booleans  of  the  same. 

5. 3. 3.1  Tickler  File 

This  is  the  analog  of  the  manual  tickler  board.  In  essence,  this  is  a matrix 
whose  rows  and  columns  represent  vehicles  and  time  intervals  and  whose 
elements  represent  characteri sties  of  interest. 

5. 3.3.2  DAVE  File 

This  is  the  analog  of  the  DAVE  board.  The  report  is  a map  annotated  with  ve- 
hicle and/or  patron  characteristics  of  interest.  If  graphical  capability  (not 
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part  of  the  proposed  software  for  development)  is  available,  it  will  be  used. 
Otherwise,  the  analog  information  is  to  be  approximated  digitally. 


5.4  INTERNALLY  GENERATED  DATA 

These  data  are  those  which  have  permanent  or  at  least  long-term  value.  They 
supply  a history  of  the  system  operation  which  is  directly  required  for  modi- 
fication and  calibration  of  the  static  data.  Additionally,  they  are  useful 
for  studying  both  the  control  procedures  and  management  of  the  paratransit 
system  as  a whole.  They  also  provide  input  for  noncontrol  software  for  sat- 
isfying reporting,  accounting,  and  billing  requi rements.  The  file  entity  is 
the  patron;  the  elements  are: 

(1)  Name  (T); 

(2)  Identification  (F); 

(3)  Address  (T); 

(4)  Geocode  (F); 

(5)  Telephone  (F); 

(6)  Address  Prefix  (F  and  T); 

(7)  Sponsoring  Agency  (F  and  T); 

(3)  Billable  Agency  (F  and  T); 

(9)  Authorization  Starting  Date  (F); 

(10)  Authorization  Termination  Date  (F); 

(11)  Destination  (F  and  T); 

(12)  Destination  Geocode  (F); 

(13)  Class  (F); 

(14)  Date  of  Service  (F); 
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(15)  Times  (F): 


(a)  Request  Received; 

(b)  Requested  Service; 

(c)  Assignment; 

(d)  Estimated  Pickup; 

(e)  Estimated  Dropoff; 

(f)  Minimum  Travel  Time; 

(g)  Actual  Pickup; 

(h)  Actual  Dropoff; 

(i)  Disutility; 

(j)  Cancellation;  and 

(k)  No-Show. 

(16)  Vehicle 

5.5  DATA  CONSTRAINTS 

There  are  no  unusual  data  constraints  except  that  the  volume  of  static  data 
required  is  rather  large  and  may  be  only  weakly  related  to  the  number  of 
control  transactions.  The  portability  requirement  implicitly  precludes 
substantial ly  different  file  structure  for  different  systems.  Accessibility 
requirements  appear  to  be  unrelated  to  system  size  except  as  response  time  is 
affected. 
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6.  DATA  COLLECTION 


6.1  REQUIREMENTS  AND  SCOPE 

Only  the  structure  of  the  data  bases  will  be  provided  by  the  developers;  there 
will  be  no  formal  data  collection  activity.  However,  certain  default  data 
bases  may  be  provided  for  use  prior  to  local  data  collection  and/or  calibra- 
tions. For  example,  a travel  speed  table  may  be  constructed  by  the  developer 
using  uniform  travel  speeds;  this  is  usable  for  training  and  initial  operation 
but  should  be  updated  fairly  quickly. 

User  data  collection  similarly  can  be  phased  in  several  different  ways. 

Either  certain  data  bases  (landmark  or  street  address  as  examples)  could  be 
defined,  or  data  bases  could  be  synthesized  (for  the  address  file,  each  street 
could  be  considered  a single  straight  line  segment). 

Incomplete  or  inaccurate  data  will  obviously  affect  the  performance  of  the 
system.  The  design  concept  will  accommodate  local  errors  without  catastrophic 
failure.  The  quality  of  the  routing/scheduling  procedure  is  intended  to  be  as 
good  as  the  input. 

6.1.1  Source  of  Input 

All  data  used  for  routing/scheduling  are  expected  to  be  entered  from  the  con- 
trol center  of  the  paratransit  agency.  Static  data  bases  may  be  entered  or 
modified  by  control  staff  or  some  other  group. 
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6.1.2  Input  Media 


Input  media  will  be  those  conventionally  used  for  batch  processing  (cards  and 
magnetic  tape)  and  CRT-keyboard  terminals.  For  the  development,  all  input  is 
expected  to  be  digital. 

6.1.3  Recipients 

For  the  control  system  itself,  all  recipients  of  output  will  be  within  the 
control  group.  The  only  exception  foreseen  is  if  some  other  group  is  opera- 
tionally responsible  for  updating  data  bases  and/or  reduction  of  operational 
data  to  provide  inputs  for  updating.  Of  course,  output  data  may  provide 
inputs  to  other  software  which  produces  reports  targeted  for  other  users. 

6.1.4  Output  Media 

For  internal  (routing/scheduling)  the  output  media  expected  are  digital  CRT 
and  medium  speed  hard  copy.  Graphic  (CRT  and/or  hard  copy)  may  be  used. 

6.1.5  Critical  Values 

No  particular  values  for  any  data  element  appear  to  be  critical. 

6.1.6  Scales  of  Measurement 

The  scales  and  measures  will  be  those  used  by  or  familiar  to  manual  operators. 
Some  variables  such  as  penalties  or  disutilities  may  be  new,  but  their  units 
will  be  familiar  and  the  concept  will  be  transparent. 
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6.1.7  Conversion  Factors 


Analog  to  digital  devices,  if  used,  should  not  pose  any  problems;  accuracy  and 
precision  of  conventional  procedures  is  more  than  adequate.  The  units  for  in- 
put and  output  will  be  identical;  those  used  internally  are  immaterial  to  the 
user. 


6.1.8  Frequency  of  Updating 

The  desirable  frequency  of  updating  of  static  data  is  more  dependent  upon  the 
volume  of  changes  than  upon  a fixed  time  interval.  The  frequency  of  updating 
would  be  expected  to  differ  by  user  with  the  primary  determinant  being  the 
change  in  patrons.  For  calibration  updates  (dwell  times,  travel  times,  etc.), 
there  should  be  enough  observed  data  to  produce  improved  parameter 
estimates. 

At  most,  updates  will  be  performed  daily;  a more  likely  update  interval  will 
be  weekly.  After  some  period  of  successful  operations,  it  is  feasible  that 
calibration  updating  will  not  be  required  at  all.  Whatever  the  required  fre- 
quency, it  does  not  have  a large  impact  upon  response  time  requi rements . 

6.1.9  Frequency  of  Input 

Dynamic  input  into  the  system  is  a direct  function  of  the  patronage  except  for 
subscription  or  repeat  patrons  who  may  be  retrieved  from  the  static  data 
bases.  At  worst,  the  dynamic  input  is  one  entry/patron  trip  (actually  a lit- 
tle less  since  for  round  trips,  most  if  not  all  of  the  return  trip  information 
can  be  generated  with  the  original  trip). 
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Input-output  internal  to  the  control  system,  modul e-to-modul e transfers,  will 
be  of  much  higher  volume.  The  volume  is  controllable  in  normal  operation  by 
good  file  design;  a mix  of  alternating  manual  and  automated  procedures  is  the 
worst  case  since  input-output  also  implies  transformation.  Back-up  and 
restart  procedures  are  expected  to  be  particularly  difficult. 

6.2  INPUT  RESPONSIBILITIES 

Except  for  default  or  synthesized  data  bases  to  be  supplied  by  the  developer, 
all  input  data  is  the  responsibility  of  the  user. 

6.3  PROCEDURES 

For  software  development,  the  data  structures  are  far  more  critical  than  data 
element  values.  A basic  premise  in  development  philosophy  is  that  all  parts 
of  the  system  must  be  amenable  to  incremental  and  evolutionary  changes  at  each 
operational  site.  Primarily,  this  is  to  insure  portability  and  transparency 
but  a concomitant  impact  is  that  data  gathering  procedures  may  be  ad  hoc  and 
differ  by  operational  site. 
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